Currently, the demand for time synchronization and frequency synchronization of high precision has been increasing in fields related to communication appliances, industries, AV, measurements, and automobiles, and a standards for realizing a packet-based time synchronization method is standardized by IEEE 1588.
IEEE 1588 is a standard for laying down a time synchronization protocol applicable to Ethernet. With IEEE 1588, a protocol called PTP (Precision Time Protocol) is defined. With this protocol, time synchronization is performed with an IP (Internet Protocol) packet or a MAC frame specified as an Ethernet type.
FIG. 1 illustrates a block configuration and a clock configuration, which are intended for the time synchronization of IEEE 1588 in a communication apparatus.
In a GrandMaster mode node 10, a master of time information, receives TOD (Time of Day: time information) and PPS (Pulse per Second) from a GPS (Global Positioning System) receiver, and synchronizes the local node to a standard time. The GrandMaster mode node 10 propagates time information to an adjacent Boundary clock mode node 11 with PTP via a communication line. A portion for controlling a relay of the time information is Time Management units 13-1 to 13-3. A node that relays the time information is referred to as a Boundary clock mode node, whereas a termination point node of time information propagation is referred to as an Ordinary clock mode node. All of these nodes are time-synchronized sequentially from the GrandMaster mode node.
Each of the nodes includes an RTC (Real Time Clock) 14-1 to 14-4 for performing PTP, and a Time Stamp unit 15-1 to 15-4 for time-stamping a time of a transmission/reception of a PTP packet in a line interface unit (Ethernet MAC Processing unit) 16-1 to 16-4. The nodes can be time-synchronized with clock precision of a time resolution of the Time Stamp. In conformity with IEEE 1588 PTP, time synchronization can be implemented on the order of nanoseconds as its precision.
To perform time synchronization, also an operation clock of an apparatus needs to be synchronized. A clock signal from an external oscillator (external PRS) is input to the GrandMaster mode node 10. A PLL (Phase Locked Loop) 17-1 of the GrandMaster mode node 10 generates a reference clock the timing of which is synchronized with the clock signal from the external oscillator. This reference clock is transferred to the Boundary clock mode node 11 and an Ordinary clock mode node 12 by using Synchronous Ethernet. In the Boundary clock mode node 11 and the Ordinary clock mode 12, timings are synchronized by the PLLs 17-2 and 17-3.
Time stamp added when a PTP message is generated is generated with an RTC that is operated with software by a CPU 9-1 to 9-4 that controls the line interface unit 16-1 to 16-4.
FIG. 2 is a sequence diagram illustrating procedures of the time synchronization.
IEEE 1588 PTP has four types of messages such as Sync, Follow_Up, Delay_Req, and Delay_Resp. Time Stamp information set in a field of these messages are transmitted from a Time server to a Client. Finally, four time stamps t1 to t4 each including a processing delay arrive at the Client as illustrated in FIG. 2. A delay from the Time server to the Client is calculated based on these time stamps, and the Client is time-synchronized with the Time server. Specific procedures are described below.
The Time server transmits the Sync message to the Client. At this time, the Time server stores the transmission time t1 of the Sync message, and transmits Time Stamp that records t1 by using the Follow-Up message transmitted next.
Upon detection of the Sync message, each of relay nodes 20-1 and 20-2 called a Transparent clock calculates a processing delay based on a difference between a reception time and the transmission time. This processing delay is added to the Follow-Up message received next.
Upon receipt of the Sync message, the Client stores the reception time t2. Moreover, the Client extracts t1 and the processing delay from the Follow_Up message received next, and stores the t1 and the processing delay.
The Client transmits the Delay_Req message, and stores the transmission time t3.
Upon detection of the Delay_Req message, each of the relay nodes 20-1 and 20-2 called a Transparent clock calculates a processing delay based on a difference between a reception time and the transmission time. This processing delay is added to the Delay-Resp message received next in a reverse direction.
Upon receipt of the Delay_Req message, the Time server stores the reception time t4. Then, the Time server transmits a Time Stamp that represents t4 by using the Delay-Resp message transmitted next.
Upon receipt of the Delay-Resp message, the Client extracts t4 and the processing delay from the message, and stores the t4 and the processing delay.
In this way, the Client can obtain the time stamps t1 to t4 and the processing delays.
A portion excluding the processing delays of the transparent clocks in a delay between the Time server and the Client is calculated with the following equation. This simply results in a delay time of a transmission path.
      DELAY    ⁢                  ⁢    TIME    ⁢                  ⁢    OF    ⁢                  ⁢    TRANSMISSION    ⁢                  ⁢    PATH    =                    (                              t            ⁢                                                  ⁢            4                    -                      t            ⁢                                                  ⁢            1                          )            -              (                              t            ⁢                                                  ⁢            3                    -                      t            ⁢                                                  ⁢            2                          )            -              SUM        ⁢                                  ⁢        OF        ⁢                                  ⁢        PROCESSING        ⁢                                  ⁢        DELAY              2  
This equation represents a result obtained by dividing a result of subtracting a processing time (t3−t2) within the Client and a total of the processing delays of the relay nodes 20-1 and 20-2 on outward and return routes from a time (t4 to t1) from the transmission of the Sync message from the Time server to the Client up to the return of the Delay_Resp message by 2. The obtained result is a transmission path delay from the Time server to the Client.
By using the above described transmission path delay, t1, t2, and the processing delays of the Sync message, the amount of a correction for a time is calculated as follows.CORRECTION AMOUNT=t1+TRANSMISSION DELAY+SUM OF Sync PROCESSING DELAY−t2
Here, the processing delays of Sync are delays of portions indicated by a and b in FIG. 2. With this equation, the transmission path delay, and the total of the transmission path delays within the relay nodes 20-1 and 20-2 are subtracted from the transmission time needed from the Time server to the Client, and a time lag between the RTC of the Time server and that of the Client is represented as the amount of a correction. This amount of a correction is used to correct the time of the RTC within the Client.
FIG. 3 illustrates fields included in a PTP message.
transportSpecific is a value uniquely determined dependent on hardware. messageType has a value uniquely determined depending on a message type such as Sync or the like. versionPTP is a value of portDS.versionNumber member of a dataset of a message generation node. messageLength is the number of all bits of a PTP message.
domainNumber is a value of defaultDS.domainNumber member of a dataset of an ordinary clock node that generates a message, or a boundary clock node. flagField is a flag having a meaning of each message in each of bits of two bytes. For example, 1 bit of the first byte indicates a Synch/Delay_Resp message. In corretionField, a modification value of a residence time, a transmission delay or the like is set. sourcePortIdentity indicates portDS.portIdentity member of a dataset of a message generation node. sequenceID is a value for managing a message set exchanging Time Stamp. controlField is a field prepared for compatibility with hardware for PTP version 1. logMessageInterval has a value determined depending on a message type.
originTimestamp present only in a Sync message is Time Stamp of a node that has transmitted the sync message.
Within a communication apparatus, Time Stamp of a PTP message used for time synchronization of IEEE 1588 is processed with conventional software.
Specifically, there is a field called “correctionField” for correcting a generation time of a Sync message called “Origin Time Stamp” of a PTP message. Time stamp added when a packet is generated is processed by using CLK dependent on software executed by a CPU. For a time stamp added when a packet is transmitted, its time information is updated by using an RTC (Real Time Clock) synchronized with the clock dependent on the software executed by the CPU.
Conventional techniques include a technique for performing time synchronization between a slave apparatus and a master apparatus, and a technique for performing time synchronization of high precision with a small error caused by fluctuations in a propagation delay time. The conventional techniques also include a technique for performing time synchronization between a master and a slave in a network including a path having asymmetric outward and return transmission routes, or a technique for performing time synchronization to a GPS reference time of all base stations.